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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://ipr.etsi.org) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Electronic Signatures and 
Infrastructures (ESI). 



Introduction 

TS 101 903 [1] (XAdES henceforth) specifies formats for Advanced Electronic Signatures built on XML SIG [2]. That 
document defines a number of signed and unsigned optional signature properties, resulting in support for a number of 
variations in the signature contents and powerful processing requirements. 

In order to maximise interoperability in communities applying XAdES to particular environments it is necessary to 
identify a common set of options that are appropriate to that environment. Such a selection is commonly called a 
profile. 

The present document profiles TS 101 903 [1] signatures contexts where AdES signatures are used and in particular its 
use in the context of the "Directive 2006/1 23/EC [i.l] of the European Parliament and of the Council of 12 December 
2006 on services in the internal market" (EU Services Directive henceforth). 
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Scope 



The present document defines a baseline profile for XAdES that provides the basic features necessary for a wide range 
of business and governmental use cases for electronic procedures and communications to be applicable to a wide range 
of communities when there is a clear need for interoperability of AdES signatures used in electronic documents to be 
interchanged across borders. In particular it takes into account eSignature needs in the context of the EU Services 
Directive [i.l]. 

The profile defines four different conformance levels addressing incremental requirements to maintain the validity of 
the signatures over the long term, in a way that all the requirements addressed at a certain level are always addressed 
also by the levels above. Each level requires the presence of certain XAdES properties, suitably profiled for reducing 
the optionality as much as possible and referring to the forms that are specified in XAdES [1]. 

Clause 4 identifies the four conformance levels and shows how these levels might encompass the life cycle of the 
electronic signatures. 

Clause 5 provides details on the way that the requirements will be presented throughout the present document. 

Clause 6 profiles short-term related XAdES properties. 

Clause 7 profiles a XAdES signature for which a Trust Service Provider has generated a trusted token (time-mark or 
time-stamp token) proving that the signature itself actually existed at a certain date and time. 

Clause 8 profiles long-term related XAdES properties tackling the long term availability of the signature validation 
material. 

Clause 9 profiles long-term related XAdES properties tackling the long term availability and integrity of the signature 
validation material. 

NOTE: The present document makes use of certain verbal forms (e.g. may, shall, shall not and should) as key 

words to signify requirements, conforming to ETSI Drafting Rules, clause 14a [i.8]. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
referenced document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI TS 101 903: "Electronic Signatures and Infrastructures (ESI); XML Advanced Electronic 

Signatures (XAdES)". 

[2] W3C Recommendation (June 2008): "XML Signature Syntax and Processing (Second Edition)". 

[3] W3C Recommendation (March 2001): "Canonical XML Version 1.0". 

[4] W3C Recommendation (July 2002): "Exclusive XML Canonicalization Version 1.0". 

[5] W3C Recommendation (May 2008): "Canonical XML Version 1.1". 

[6] W3C Recommendation (November 1999): "XSL Transformations (XSLT) Version 1.0". 
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[7] W3C Recommendation (November 2002): "XML-Signature XPath Filter 2.0" . 

[8] ETSI TS 102 176-1: "Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters 

for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms". 

[9] ECRYPT II (European Network of Excellence in Cryptology II): "ECRYPT II Yearly Report on 

Algorithms and Keysizes". 

[10] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax". January 2005. 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] Directive 2006/1 23/EC of the European Parliament and of the Council of 12 December 2006 on 

services in the internal market. 

[i.2] Commission Decision 2009/767/EC of 16 October 2009 amended by CD 2010/425/EU of 28 July 

2010, setting out measures facilitating the use of procedures by electronic means through the 
"points of single contact" under Directive 2006/1 23/EC of the European Parliament and of the 
Council on services in the internal market. 

[i.3] ETSI TS 102 231: "Electronic Signatures and Infrastructures (ESI); Provision of harmonized 

Trust-service status information" . 

[i.4] ETSI TS 101 533-1: "Electronic Signatures and Infrastructures (ESI); Data Preservation Systems 

Security; Part 1: Requirements for Implementation and Management". 

[i.5] ETSI TS 102 640-1: "Electronic Signatures and Infrastructures (ESI); Registered Electronic Mail 

(REM); Part 1: Architecture". 

[i.6] Commission Decision 201 1/130/EU of 25 February 201 1 ; establishing minimum requirements for 

the cross-border processing of documents signed electronically by competent authorities under 
Directive 2006/1 23/EC of the European Parliament and of the Council on services in the internal 
market (notified under document C(2011) 1081). 

[i.7] ISO 8601:2004 (2004-12): "Data elements and interchange formats - Information interchange - 

Representation of dates and times". 

[i.8] ETSI Drafting Rules (EDRs). 

NOTE: Contained in the ETSI Directives: http://portal.etsi.org/Directives/home.asp . 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 
generator: any party which creates, or adds attributes to, a signature 

NOTE: This may be the signatory or any party that initially verifies or further maintains the signature. 
protocol element: element of the protocol which may be including data elements and / or elements of procedure 
service element: element of service that may be provided using one or more protocol elements 

NOTE: All alternative protocol elements provide an equivalent service to the users of the protocol. 
trust service provider: body operating one or more (electronic) Trust Services (see [i.3]) 
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verifier: entity that validates or verifies an electronic signature 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in XAdES [1] and the following apply: 
TSL Trust-service Status List (see [i.3]) 



4 Conformance Levels 

The present document defines four conformance levels as indicated below. 

Applications managing signatures conformant to requirements specified in clause 6 may claim B -Level (basic level) 
conformance. 

Applications managing signatures conformant to B -Level and also conformant to requirements specified in clause 7 
may claim T-Level (Trusted time for signature existence) conformance. 

Applications managing signatures conformant to T-Level and also conformant to requirements specified in clause 8 of 
the present document may claim LT-Level (Long Term level) conformance. 

Applications managing signatures conformant to LT-Level and also conformant to requirements specified in clause 9 of 
the present document may claim LTA-Level (Long Term with Archive time-stamps) conformance. 

These conformance levels are defined for encompassing the life cycle of electronic signature, namely: 

a) B -Level profiles incorporation of signed and some unsigned properties when the signature is actually generated. 

NOTE 1: It is considered that this level is sufficient to conform to the Commission Decision 201 1/130/EU of 
25 February 2011 [i.6]. 

b) T-Level profiles the generation, for an existing signature, of a trusted token proving that the signature itself 
actually existed at a certain date and time. 

c) LT-Level profiles the incorporation of all the material required for validating the signature in the signature. 
This level is understood to tackle the long term availability of the validation material. 

d) LTA-Level profiles the incorporation of time-stamp tokens that allow validation of the signature long time 
after its generation. This level is understood to tackle the long term availability and integrity of the validation 
material. 

NOTE 2: The levels b) to d) are appropriate where the technical validity of signature needs to be preserved for a 
period of time after signature creation where certificate expiration, revocation and/or algorithm 
obsolescence is of concern. The specific level applicable depends on the context and use case. 

All conformance levels up to LTA use properties defined in XAdES [1]. 

When signed data is exchanged between parties the sender should use at least signatures conforming to a level that 
allows the relying parties to trust the signature at the time the exchange takes place. 

NOTE 3: Archiving or preservation of electronic signatures over long term requires in general conformance to LTA 
level. The use of LTA-level is considered an appropriate preservation and transmission technique for 
signed data. Conformance to lower level is sufficient when combined with appropriate additional 
protection techniques such as use of systems compliant to TS 101 533-1 [i.4]. 

NOTE 4: The assessment of the effectiveness of other preservation and transmission techniques for signed data are 
out of the scope of the present document. The reader is advised to consider legal instruments in force and 
related standards such as TS 101 533-1 [i.4] or TS 102 640-1 [i.5] to evaluate their appropriateness. 



ETSI 



ETSI TS 103 171 V2.1.1 (2012-03) 



5 General requirements 

5.1 Algorithm requirements 

Generators are referred to applicable national laws regarding algorithms and key lengths. 

Generators are also recommended to take into account the latest version of TS 102 176-1 [8] for guidelines purposes 
and the latest ECRYPT2 D.SPA.x [9] yearly report for further recommendations, when selecting algorithms and key 
lengths. 

MD5 algorithm shall not be used as digest algorithm. 

5.2 Compliance requirements 

Profiles in the present document define requirements for generators of XAdES signatures [1]. 

A verifier shall be able to accept a signature containing any elements/properties conformant to XAdES [1], but this 
profile does not specify any processing requirement on such elements/properties present in the signature as it is meant 
to be used together with a specification describing processing during signature validation. 

Requirements are grouped in two different categories, each one having its corresponding identifier. Table 1 defines 
these categories and their identifiers. 

Table 1 : Requirement categories 



Identifier 


Requirement on generator 


M 


Generator shall include the element in 
the signature. 





Generator may include the element in 
the signature. 



Optional elements defined in XAdES [1] but not specified in the present document are treated as "O" as above. 

Certain service elements may be provided by different protocol elements at user's choice. In these cases the semantics 
of M and O defined in table 1 depend on the requirement for the service element itself. Tables 2 and 3 (each one applies 
to a different requirement on the service element) define these semantics. 

Table 2: Requirements for mandatory service with choices 



Requirement Identifier 
for the Service / 
Protocol element 


Requirement on generator 


Service = M 


Generator shall provide the service by including 
one protocol element chosen from the list of 
choices. 


Protocol Choice = 


Generator may use this protocol element for 
providing the mandatory service elements. 



Table 3: Requirements for optional service with choices 



Requirement Identifier 
for the Service / 
Protocol element 


Requirement on generator 


Service = 


Generator may provide the service by including one 
protocol element chosen from the list of choices. 


Protocol Choice = 


If the generator decides to provide the service, then 
it may use this protocol element. 
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The present document shows new requirements for each service and protocol element in tabular form. Below follows 
the structure of the table. 

Table 4: Requirements for optional service with choices 



Service / Protocol 
element 


Reference 


Requirement on 
generator 


Additional 
requirements/notes 


Service: 








Choice 1 








Choice 2 









Column Service / Protocol element will identify the service element or protocol element the requirement applies to. 
Service elements that may be implemented by different protocol elements (i.e. users may make a choice on several 
protocol elements) build tables with more than one row. 

Column Reference will reference the relevant clause of the standard where the element is first defined. The reference is 
to XAdES [1], except where explicitly indicated otherwise. 

Column Requirement on generator will contain an identifier of the requirement, as defined in table 1 , bound to the 
corresponding protocol element for the generator. 

Column Notes/Additional requirements will contain numbers referencing notes and/or letters referencing additional 
requirements. Both notes and additional requirements are listed below the table. 

Profiles may be affected by applicable regulations; hence implementers should check any national regulation that may 
affect these profiles. 



6 Requirements for B-Level Conformance 

This clause defines requirements that XAdES signatures claiming conformance to the B-Level have to fulfil. 

This clause actually profiles XAdES-BES (signatures that do not incorporate 

xades : SignaturePolicyldentif ier) and XAdES-EPES (signatures that do incorporate 

xades : SignaturePolicyldentif ier) signatures. 

In consequence, the following XAdES properties are addressed directly in this clause: 

xades : SigningCertif icate , xades : SigningTime and xades : DataOb j ectFormat. Further 
xades : SignatureProductionPlace, xades : SignerRole, xades : AllDataObj ectsTimeStamp, 
xades : IndividualDataObj ectsTimeStamp, xades : SignaturePolicyldentif ier, and 
xades : Countersignature are also inherently addressed. 

Clause 6.1 specifies the incorporation of the XAdES properties to the signature. 

Clause 6.2 specifies additional requirements for some XML Sig [2] elements, namely: ds : Keylnf o, 
ds : Signedlnf o, ds : CanonicalizationMethod, ds : Reference and ds : Transform. 

Clause 6.3 specifies additional requirements for some of the XAdES [1] properties already mentioned. More 
specifically, this clause profiles xades : SigningCertif icate, xades : SigningTime and 
xades : DataOb j ectFormat. No further requirements are defined by this profile for the rest of the XAdES 
properties already mentioned than those ones specified by XAdES [1]. 
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6.1 Incorporation of XAdES qualifying properties to the 
signature 

XAdES qualifying properties incorporation to the signature shall be direct as specified in [1], clause 6.3. 

NOTE: This means that all the XAdES qualifying properties will remain within one single 

xades : Qualif yingProperties element, which in turn will be the child of one ds : Obj ect 

element within the signature; and that in consequence no 

xades : Qualif yingPropertiesRef erence elements will be present. 

6.2 Profile of elements defined in XML Signature 
6.2.1 Placement of the signing certificate 

Table 5 



Service / Protocol element 


XML SIG [2] 
Reference 


Generator 
requirement 


Additional 
requirements/notes 


ds : Keylnf o/X509Data/X509Certif icate 


Clause 4.4.4 


M 


a, b 



Additional requirements: 

a) The generator shall include the signing certificate as content of ds : Keylnf o/X5 9Data/X5 9Cert if icate 
element. 

b) In order to facilitate path-building, generators should include in the same ds : Keylnf o/X5 9Data element as 
in note a) all certificates not available to verifiers that can be used during path building. In the case of 
signature based on qualified certificates and whose verification is expected to be based on TSLs (in particular 
on Trusted Lists as defined in CD 2009/767/EC amended by CD 2010/425/EU [i.2]), the generator should 
include all intermediary certificates forming a chain between the signer certificate and a CA present in the TSL 
which are not available to verifiers. 

NOTE 1 : A certificate is considered available to the verifier, if reliable information about its location is known and 
allows automated retrieval of the certificate (for instance through an Authority Info Access Extension or 
equivalent information present in a TSL). 

NOTE 2: In the general case, different verifiers can have different trust parameters and can validate the signer 
certificate through different chains. Therefore, generators may not know which certificates will be 
relevant for path building. However, in practice, such certificates can often clearly be identified. In this 
case, it is advised that generators include them unless they can be automatically retrieved by verifiers. In 
the specific case of a signature meant to be validated through TSL, it is advised to include at least the 
unavailable intermediary certificates up to but not including the CAs present in the TSLs, since the TSL is 
information that is shared globally by all verifiers. 



ETSI 



11 



ETSI TS 103 171 V2.1.1 (2012-03) 



6.2.2 Canonicalization of ds : signedinf o element 



Table 6 



Service / Protocol element 


Reference 


Generator 
requirement 


Additional 
requirements/notes 


Service: canonicalization of ds : signedinf o element 




M 


a 


ds : Canonical izationMethod ■ s Algorithm attribute set to: 
"http: //www.w3 .org/2006/l2/xml-cl4nll M 


XML Sig [2], 

clause 4.3.1 

Can. XMLV1.1 [5] 


O 


1 


ds : CanonicalizationMethod ■ s Algorithm attribute set to: 
"http://www.w3 ,org/2001/10/xml-exc-cl4n#" 


XML Sig [2], 

clause 4.3.1 

Ex. Canon. [7] 


O 


2 


ds : CanonicalizationMethod' s Algorithm attribute set to: 
"http://www.w3 .org/TR/200l/REC-xml-cl4n-20010315" 


XML Sig [2], 

clause 4.3.1 

Can. XMLV1.0[3] 


O 


3 


ds : CanonicalizationMethod' s Algorithm attribute set 

to: "http: //www.w3 . org/2006/12/xml- 

cl4nll#WithComments" 


XML Sig [2], 

clause 4.3.1 

Can. XMLV1.1 [5] 




a, 
4,7 


ds : CanonicalizationMethod ' s Algorithm attribute set to: 

"http: //www.w3 . org/2 1/10/xml-exc- 

cl4n#WithComments " 


XML Sig [2], 

clause 4.3.1 

Ex. Canon. [7] 




a, 
5,7 


ds : CanonicalizationMethod ' s Algorithm attribute set to: 

"http://www.w3 ,org/TR/200l/REC-xml-cl4n- 

20010315 #Wi t hComment s " 


XML Sig [2], 

clause 4.3.1 

Can. XMLV1.0[3] 




a, 
6,7 



Additional requirement: 

a) The generator should not use canonicalization algorithms "with comments". 

NOTE 1: This URI value corresponds to Canonical XML vl.l (omits comments). 

NOTE 2: This URI value corresponds to Exclusive Canonicalization [4] (omits comments). 

NOTE 3: This URI value corresponds to Canonical XML vl.O (omits comments). 

NOTE 4: This URI value corresponds to Canonical XML vl.l (with comments). 

NOTE 5: This URI value corresponds to Exclusive Canonicalization (with comments). 

NOTE 6: This URI value corresponds to Canonical XML vl.O (with comments). 

NOTE 7: Support of canonicalization algorithms "with comments" is for residual interoperability in the signature 
verification process. 

6.2.3 Profile of ds : Reference element 

Table 7 



Service / Protocol element 


XML Sig 
Reference [2] 


Generator 
requirement 


Additional 
requirements/notes 


ds : Reference 


Clause 4.3.3 


M 


a, b 



Additional requirements: 

a) The generator shall create as many ds : Reference element as signed data objects (each one referencing one 
of them) plus one ds : Reference element referencing xades : SignedProperties element. 

b) The ds : Reference's URI attribute referencing signed data objects may have as values references that are 
or are not "same-document" references as defined in [10], section 4.4. 
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6.2.4 Transforms within ds : Reference element 



Table 8 



Service / Protocol element 


Reference 


Generator 
requirement 


Additional 

requirements/ 

notes 


Service: Transforms applicable within ds : Reference element 







a, b 


ds : Transform ■ s Algorithm attribute set to: 
"http: //www.w3 .org/2000/09/xmldsig#base64" 


XML Sig [2], 
clause 6.6.2 







ds : Transform' s Algorithm attribute set to: "http://www.w3.org/TR/1999/REC- 

xpath-19991116" 


XML Sig [2], 
clause 6.6.3 







ds : Transform' s Algorithm attribute set to: 

"http : //www. w3 . org/2000/09/xmldsig#enveloped-signature" 


XML Sig [2], 
clause 6.6.4 







ds : Transform ' s Algorithm attribute set to: 
"http://www.w3.org/TR/l999/REC-xslt-19991116" 


XML Sig [2], 

clause 6.6.5 

XSLT [6] 







ds : Transform ' s Algorithm attribute set to: 
"http: //www.w3 .org/2002/06/xmldsig-f ilter2" 


XPathFilter2[7] 







ds : Transform ' s Algorithm attribute set to: " 
http : //schemas . openxml formats . org/package/2006/RelationshipTransf orm" 










Additional requirements: 

a) 



b) 



Generator should limit the range of transforms used in the signatures to the ones identified in table 8 of the 
present document. 

Requirements defined in clause 6.2.2 of the present document shall apply when ds : Transform ' s 
Algorithm attribute is set to any of the canonicalization algorithms identifiers mentioned in that clause. 



6.3 



Profile of XAdES elements 



6.3.1 Profile of xades : SigningCertif icate element 



Table 9 



Service / Protocol element 


XAdES 
Reference [1] 


Generator 
requirement 


Additional 
requirements/notes 


xades : SigningCertif icate 


Clause 7.2.2 


M 


a, 1 


xades : SigningCertif icate/CertDigest 


Clause 7.2.2 


M 


b 


xades : SigningCertif icate/IssuerSerial 


Clause 7.2.2 


M 


c 



Additional requirements: 

a) The generator shall not generate xades : Cert children's uri optional attribute. 

b) xades : SigningCertif icate/CertDigest element shall contain the digest value of the signing certificate 
present within ds : Keylnf o element and the identifier of the corresponding digest algorithm. 

c) xades : SigningCertif icate/IssuerSerial element shall contain the IssuerSerial of the signing 
certificate present within ds : Keylnf o element. 

NOTE 1: The presence of the signing certificate within ds : Keylnf o ensures a way to locate it (on the basis of 

digest equality with the value within xades : SigningCertif icate/CertDigest) within the signature. 
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6.3.2 Profile Of xades : SigningTime element 

Table 10 



Service / Protocol element 


XAdES 
Reference [1] 


Generator 
requirement 


Additional 
requirements/notes 


xades : SigningTime 


Clause 7.2.1 


M 


a 



Additional requirement: 

The generator shall include the claimed UTC time when the signature was generated as content of this 
element. 



a) 



6.3.3 Profile Of xades : DataOb j ectFormat element 



Table 11 



Service / Protocol element 


XAdES 
Reference [1] 


Generator 
requirement 


Additional 
requirements/notes 


xades : DataObj ectFormat 


Clause 7.2.5 


M 


a, 1 


xades : DataObj ectFormat/Description 


Clause 7.2.5 







xades : DataObj ectFormat/Obj ectldentif ier 


Clause 7.2.5 







xades : DataObj ectFormat/MimeType 


Clause 7.2.5 


M 




xades : DataObj ectFormat/Encoding 


Clause 7.2.5 







xades : DataObj ectFormat's Obj ectRef erence attribute 


Clause 7.2.5 


M 





Additional requirement: 

a) Implementations claiming conformance to the present document shall generate one 

xades : DataObj ectFormat for each signed data object, except the xades : SignedProperties element. 

NOTE 1: XAdES [1] specification establishes that this signed property "qualifies one specific signed data object". 
This is done by forcing that Obj ectRef erence attribute refers to a ds : Reference. However XAdES 
does not mandate this ds : Reference to be a child of ds : Signedlnf o; it actually could be a 
ds : Reference within a signed ds : Manifest, as the object referenced in this way is also a signed 
object. 



7 Requirements for T-Level Conformance 

This clause defines those requirements that XAdES signatures conformant to B -Level, have to fulfil to also be 
conformant to T-Level. In consequence, XAdES signatures claiming conformance to the T-Level of the present profile 
shall be built on signatures conformant to the B -Level. 

A XAdES signature conformant to T-Level shall be a signature conformant to B -Level for which a Trust Service 
Provider has generated a trusted token (time-mark or time- stamp token) proving that the signature itself actually existed 
at a certain date and time. 

NOTE: XAdES signatures conformant to T-Level of the present specification are, in consequence, XAdES -T 
signatures suitably profiled as per the requirements defined in this clause. 

Table 12 further profiles the provision of the trusted token that proves existence of the signature at a certain date and 
time. 
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Table 12 



Service / Protocol element 


XAdES 
Reference [1] 


Generator 
requirement 


Additional 
requirements/notes 


Service: trusted time for existence of the signature 




M 




xades : SignatureTimeStamp 


Clause 7.3 





a, b 


Time-mark 


Clause 7.3 





c 



Additional requirements: 

a) The present profile recommends usage of time-stamps as attestation of the time for existence of the signature 
instead of time-marks. 

b) A XAdES signature claiming conformance to the T-Level may contain several 

xades : SignatureTimeStamp elements. Each xades : SignatureTimeStamp element shall contain only 
one time-stamp token. 

c) If a time-mark is used, then no additional property is incorporated in the signature. It is the responsibility of 
the TSP generating the time-mark to provide the needed trust on the signature time. 



8 



Requirements for LT-Level Conformance 



This clause defines those requirements that XAdES signatures conformant to T-Level, have to fulfil to also be 
conformant to LT-Level. In consequence, XAdES signatures claiming conformance to the LT-Level of the present 
profile shall be built on signatures conformant to the T-Level. 



8.1 



Profile of XAdES elements 



XAdES signatures conformant to LT-Level shall not incorporate any of the following XAdES unsigned attributes: 

xades : CompleteCertif icateRef s, xades : CompleteRevocationRef s, 

xades : AttributeCertif icateRef s, xades : AttributeRevocationRef s, xades : SigAndRef sTimeStamp, 

and xades : Ref sOnlyTimeStamp. 

NOTE: The requirements above are meant to highly reduce optionality. 

XAdES signatures conformant to LT-Level are built by direct incorporation to XAdES -T signatures conformant to the 
T-Level, of XAdES unsigned properties containing values of certificates and values of certificate status. In 
consequence, this clause defines additional specific requirements for the following unsigned XAdES properties: 

xades : Certif icateValues, xades :RevocationValues, xades : AttrAuthoritiesCertValues, 
xades : AttributeRevocationValue , and xadesvl41 :TimeStampValidationData. 

Clauses below define additional requirements for these XAdES unsigned properties. 

8.1 .1 Profile Of xades : Certif icateValues property 

Table 13 



Service / Protocol element 


XAdES 
Reference [1] 


Generator 
requirement 


Additional 
requirements/notes 


Service: certificate values 


Clause 7.6.1 


M 




xades : Certif icateValues 


Clause 7.6.1 





a, b, c 



Additional requirements: 

a) 



Implementations claiming conformance to this profile shall include in this property the set of certificate values 
that, in addition to the certificate values present within ds : Keylnf o element, build up the full set of 
certificates (including the trust anchor when it is available in the form of a certificate) used to validate the 
signature. 
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b) In situations different from those ones identified in clause 6.2.1 of the present document, requirements a) and 
b), applications should include certificate values within xades : Cert if icateValues property. 

c) Duplication of certificate values within the signature should be avoided. 

8.1 .2 Profile Of xades : RevocationValues property 

Table 14 



Service / Protocol element 


XAdES 
Reference [1] 


Generator 
requirement 


Additional 
requirements/notes 


Service: revocation values 


Clause 7.6.2 


M 




xades : RevocationValues 


Clause 7.6.2 





a, b, c 



Additional requirements: 

a) Implementations claiming conformance to this profile shall include in this property the set of revocation 
values that, in addition to the revocation values present within ds : Keylnf o element, build up the full set of 
revocation values used to validate the signature. 

b) Applications should include certificate status values within xades : RevocationValues property instead 
within ds:KeyInfo element. 

c) Duplication of revocation values within the signature should be avoided. 

8.1 .3 Profile of xades:AttrAuthoritiesCertValues property 

If the signature contains attribute certificates within xades : Signer Role signed property, implementations claiming 
conformance to this profile shall include in this property the set of attribute authority values that, in addition to the rest 
of certificate values present in the signature, build up the full set of certificates required for validating the attribute 
certificates. 

8.1 .4 Profile of xades:AttributeRevocationValues property 

If the signature contains attribute certificates within xades : Signer Role signed property, implementations claiming 
conformance to this profile shall include in this property the set of revocation values that, in addition to the rest of 
revocation values present in the signature, are used for validating the attribute certificates. 

8.1 .5 Validation material for time-stamp tokens 

This clause further profiles the incorporation of the validation material for time- stamp tokens within XAdES signatures 
compliant with LT-Level. 

Table 15 



Service / Protocol element 


XAdES 
Reference [1] 


Generator 
requirement 


Additional 
requirements/notes 


Service: validation data for time-stamp tokens 




M 


1 


xadesvl41 :TimeStampValidationData 


Clause 8.1 of 
version 1.4.2 





2 


embedded in time- stamp token itself 










NOTE 1 : This ensures that the signature profiled actually contains all the validation material needed. 

NOTE 2: Although this profile allows incorporation of the validation material within the time-stamp token itself, 
within the new XAdES element, or within both, applications should implement support for 

xadesv!41 :TimeStampValidationData. 
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9 



Requirements for LTA-Level Conformance 



This clause defines those requirements that XAdES signatures conformant to LT-Level, have to fulfil for also be 
conformant to LTA-Level. In consequence, XAdES signatures claiming conformance to the LTA-Level of the present 
profile shall be built on signatures conformant to the LT-Level. 

A XAdES signature conformant to LTA-Level shall be a signature conformant to LT-Level to which one or more 

xades : ArchiveTimeStamp (or xadesvl41 : ArchiveTimeStamp) have been directly incorporated. 

NOTE 1: This conformance level specifies a profile for XAdES-A signatures. 

NOTE 2: As stated in XAdES [1], XAdES-A form may help to validate the signature beyond any event that may 
limit its validity. 

Table 16 



Service / Protocol element 


XAdES 
Reference [1] 


Generator 
requirement 


Additional 
requirements/notes 


Service: add archive time-stamp 




M 




xades : ArchiveTimeStamp 


Clause 7.7 





a, b, c, d, e 


xadesv!41 : ArchiveTimeStamp 


Clause 8.2 of 
version 1.4.2 





a, b, c, d, e 



Additional requirements: 

a) Signatures conformant to LTA-level shall incorporate at least one xades : ArchiveTimeStamp or one 
xadesvl41 : ArchiveTimeStamp property. 

b) Signatures conformant to LTA-level may also have more than one xades : ArchiveTimeStamp or 
xadesvl41 : ArchiveTimeStamp properties. Presence of both types of properties shall be conformant to the 
transition strategy specified in clause 9.1. 

c) xades : ArchiveTimeStamp and xadesvl4 1 : ArchiveTimeStamp within signatures conformant to the 
LTA-Level may contain more than one time-stamp token issued by different TSAs. 

d) Before generating and incorporating any of the two properties profiled in this clause, applications claiming 
conformance to this profile, shall include all the validation material required for verifying the electronic 
signature. This validation material includes all the certificates and all certificate status information (like CRLs 
or OCSP responses) required for: 

validating the signing certificate; 

validating any attribute certificate present in the signature; and 

validating the signing certificate of any previous time- stamp token already incorporated in the signature 
within any XAdES time-stamp token container property (including, of course, 

xades : ArchiveTimeStamp and/or xadesvl41 : ArchiveTimeStamp). 

e) Implementations claiming conformance to the present profile shall respect the transition strategy specified in 
clause 9.1 of the present document. 

9.1 Transition strategy for ArchiveTimeStamp frameworks 

Before 20 13/0 1/01 TOO: 00: 00 UTC, applications claiming conformance to this profile, may generate and add 

xades : ArchiveTimeStamp or xadesvl41 : ArchiveTimeStamp properties. Applications capable to manage both, 

should add and generate xadesvl41 : ArchiveTimeStamp. 

NOTE 1: Date and time formats in this clause conform to ISO 8601:2004 [i.7]. 
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Applications claiming conformance to this profile shall not generate and add xades : ArchiveTimeStamp properties 
to the signatures from 20 13/0 1/01 TOO: 00: 00 UTC onwards. From 2013/01/01T00:00:00 UTC, applications claiming 
conformance to this profile shall generate and incorporate exclusively xadesvl41 : ArchiveTimeStamp properties 
into the signatures. 

Before 20 13/0 1/01 TOO: 00: 00 UTC, applications claiming conformance to this profile shall consider conformant to this 
profile any XAdES signature including xades : ArchiveTimeStamp and/or xadesvl41 : ArchiveTimeStamp only if 
the signature fulfils all the requirements specified in the clauses above. 

Starting from 20 13/0 1/01 TOO: 00: 00 UTC, applications claiming conformance to this profile shall consider conformant 
to this profile any XAdES signature including one or more xades : ArchiveTimeStamp properties if it fulfils all the 
requirements specified in the clauses above and it may be ascertained that all the time-stamp tokens contained within 
these properties were generated before 2013/01/01T00:00:00 UTC. 

This transition strategy results in an additional requirement on the transform chains to be used in signatures that may be 
evolved towards XAdES-A. Applications that generate signatures before 2013/01/01T00:00:00 UTC, and that know in 
advance that xades : ArchiveTimeStamp properties are used for upgrading the generated signature, or that are 
uncertain about how the upgrade will be done, should fulfil the following requirement: ds : Reference elements used 
for signing ds : Ob j ect elements shall contain only transforms chains that result in XML node sets or transforms 
chains whose last transform is a canonicalization transformation. 

NOTE 2: If this requirement is not ensured, checks of xades : ArchiveTimeStamp might fail. In fact, this was 
the reason why xadesvl41 : ArchiveTimeStamp was defined. 
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